The manufacturing of integrated circuit (IC) devices can be conceptualized as including a “front end” and a “back end”. A typical front end of a process can include a “wafer sort”. A wafer sort can be the testing of IC devices in wafer form. That is, devices can still be formed as part of the wafer, typically a silicon wafer, in which they have been fabricated. Subsequently, a wafer can be cut (e.g., sawn, laser cut) to separate the individual IC devices, each of which is referred to as a die (or “chip”).
A typical back end of a manufacturing process can include packaging IC devices received in die form, into a predetermined type of IC package. Typically, packaged devices are placed into a tester and sorted according to failure and/or performance criteria.
Both front end (sort) and back end (package) sort can be very important in ensuring quality control for electronic device manufacturers. Such testing can also be used to gather data, which generates information to improve quality, yields, and costs.
Conventional data gathering and information analysis solutions used at sort or package test include downloading all test summaries and gathering test counters. Test counters include counts of how many failures a particular test-algorithm generates over a selected sample size. Test counters can be searched for tests that have a zero or very low (parts per million) ppm fail rate.
Conventionally, every test in a test program can have its associated fail test counter. For such a test counter, each time the associated test is failed, the test counter can be incremented by 1 and the tested die can be “binned out”. For example, if there are 20 tests and a die fails the first test, the test counter for the test can be incremented, and the die can be tagged as a fail, and testing for that die will be discontinued. In this way, failing die can be identified and removed from any further testing.
Referring now to FIG. 12, a table is shown that illustrates an example of conventional fail test counters for a wafer sort operation. FIG. 12 shows test counters for five wafer sort tests: Tests 18, 28, 29, 63, and 77. Test 18 shows that the test associated to this counter has 252 failures in testing the whole wafer, test 18 shows 6 failures, etc. It is understood that FIG. 12 shows only those tests that have generated a failure. Test counters of other tests that have zero failures are not shown.
By accumulating all test summaries like those of FIG. 12, a user can find tests that are not listed (e.g. have zero failures), or that have a low ppm rate of failure. Such tests can then be considered candidates for removal from an overall test program.
Conventionally, prior to removing a test from a test program, it has been considered necessary to ensure that removal of the test does not allow failing devices to escape an overall test program. Thus, a candidate test or tests can be disabled, and then numerous wafers (e.g., thousands of die), can be retested to observe if any change in overall testing results has occurred. If no change occurs, the candidate test(s) can be removed from the test program. This can be costly to implement as increased testing time can translate into increase costs.
Conventionally, test counters can have a primary purpose of differentiating test failures that are grouped into a single “hard-bin” category. For example, a “Bin 7” may contain the sum of failures for multiple tests: Low-Corner1 (tn 130), Low-Corner2 (tn 131), Hi-Corner-1 (tn 230), and Hi-Corner-2 (tn 231), where each “Corner” can represent a limit in acceptable performance. Conventional test counters can thus be variables used to cumulatively count how many times each test fails, allowing differentiation between each test. The example of “Bin-7” above shows the sum of four preceding tests.
In a conventional solution, test counters are generated only from sort summaries. Every time a test fails it increments a counter. The conventional solution can perform a front end to back end correlation to ensure that tests removed from wafer sort with zero or low ppm fails rates do not end up missing failures appearing at a back end of the manufacturing process. Such a conventional approach can require considerable engineering work to gather the necessary data, which can expensive and slow. Further, such approaches may yield results for only a limited sample size.
It is noted that conventional approaches to correlating front end to back end test results do not provide information on whether a particular test is unique in its test coverage. Furthermore, when dealing with multiple family densities, the conventional solution may only compare defect density by device, as opposed to by family.
As understood from above, a goal of the conventional solution can be to disable tests at a front end (FE) or a back end (BE) that are non-value added (i.e., do not capture any defects). In such an approach, a test in a front-end flow can be removed, and tests can be executed with a resulting reduced test sequence. A “Qualification Test Plan (QTP)” can then be performed in a back-end to observe if quality has remained unchanged. If quality and yield is the same in the BE, the FE test can be disabled.
The above conventional solution can be inaccurate and inefficient because there can be no direct way of telling which die fails which particular tests. Furthermore, the benefit realized by such an approach can be limited, as only the zero failure tests can be removed (and such tests can be rare) and tests having a low ppm fail rate require a thorough correlation between front and backend before they can be removed.